not sure this is the fix we need, basically step here is not about the number of frames, is about the size of each step. I feel like the problem is in animator (

There is also a problem when getSteps returns 1

As described in #184, the number of steps is correct, the problem is the size of the steps. For the original case, (end-start)/steps = 360/7 = 51 months (wrong); while (end-start)/(steps-1) = 360/6 = 60 months (correct).

Good point re: getSteps returning 1 though, I presume step should be set to 0 in that case?

This is more or less how the timeline is. Each change in the timeslider is represented by a numbered vertical line. The duration of every step is the longitude of the horizontal segments. Probably the position/value should reflect the midpoint of the step instead of its beginning, like it's doing now.

0     1     2     3     4
|_____|_____|_____|_____|_____

With the current layout, we're not displaying the end of the timeline properly. For long steps, this was addressed the other day by specifying ranges instead of exact dates, so it looks a bit like this:

  0-1   1-2   2-3   3-4   4-5
|_____|_____|_____|_____|_____

@fdansv, I'm not following you here. If there are 5 frames, there should only be 4 steps:

 Frames
 0     1     2     3     4
 |_____|_____|_____|_____|
    1     2     3     4 
    Steps

So if you simply lengthen the steps a little, it will cover the entire data set. Or am I missing something?